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ABSTRACT 


The ability to develop information systems within cost and schedule is a 
difficult task for the DoD. The Systems Dynamics Model of Software Project 
Management is an interactive, computer simulation which allows for the 
investigation of decision making in a software development environment. 

In this thesis the author investigates the impact of risk on dynamic decision 
making in software project management. Graduate students participate as project 
managers making management decisions pertaining to total staff acquisition, its 
allocation to development versus quality assurance, and cost and schedule 
adjustments. Data analyses reveal that risk does significantly impact decision 
making and in turn project performance in terms of final cost and duration. 
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I. INTRODUCTION 


A. BACKGROUND 

Developing and maintaining software that is acceptable to the end user continues 
to challenge the Department of Defense (DoD). The DoD currently spends about $9 
billion each year on general purpose automated data processing equipment, software, and 
related services [Ref. 1]. With increasingly constrained budgets, improved management 
can lead to significant cost savings. 

The General Accounting Office (GAO) reported that cost overruns and schedule 
slippages plague DoD systems [Ref. 2]. Surveys of experienced project managers 
identify personnel shortfalls, unrealistic schedules and budgets, and a continuing stream 
of requirement changes as serious sources of risk on software projects. Postmortems of 
software project disasters reveal that their problems would have been avoided or strongly 
reduced with an explicit early concern for identifying and resolving high-risk elements. 
[Ref. 3] New concepts firom behavioral decision theory have sparked research into human 
decision making. 

Behavioral decision theory concludes that people make choices using only a few 
sources of information processed with simple rules of thumb. Morecroft modeled the 
idea that only a few information flows actually penetrate to the heart of the decision 
function, passing through several cognitive and organizational filters, where they 
influence the choices and actions of the individual. The influence of behavioral decision 
theory on system dynamics can be seen in the development of microworlds or models 
that represent organizations as decision making/information processing systems involving 
many players, with multiple (often conflicting) goals and limited processing capability. 
[Ref. 4] 

The Systems Dynamics Model (SDM) of Software Project Management models 
the dynamic nature of software project development [Ref. 5]. This simulation-based 
model has been used to conduct micro-empirical research on dynamic decisions made by 
software project managers [Ref. 6-11]. 
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B. PURPOSE OF RESEARCH 


The purpose of this thesis is to design and conduct an experimental investigation 
into the effects of risk on software project management. The SDM of Software Project 
Management will be used to study in a controlled environment, how project managers 
handle risk factors, how perceived risk affects decision making, and in turn project 
outcome in terms of final cost and schedule. 

C. SCOPE OF RESEARCH 

The scope of this research includes the experimental design, development of 
software to support the design, preparation of documentation and instruction sets for the 
participants, tailoring of the gaming interface to include risk factors, providing additional 
report capabilities, execution, and performance assessment of the allocation of resources 
by differing group project managers. Care was taken in the preparation of additional 
report capabilities and smoothing of the instruction sets in an effort to prevent 
introducing external biases. This research was conducted in a single project 
environment. 

D. LIMITATIONS 

Forty-one graduate students at the Naval Postgraduate School participated in the 
experiment as surrogates for software project managers. These students were in their 
seventh quarter of a masters program in Information Technology Management. They 
have completed significant course work and posses several years of practical managerial 
experience. These students also participated in a similar experimental investigation on 
the effect of goals on dynamic decision making as part of a software engineering course 
requirement. 


2 



E. THESIS ORGANIZATION 

Chapter II is a detailed description of the experimental design and the 
methodology used. The design includes preparing the gaming interface, the software, 
the documentation, conducting the practice experiment, and making final preparations. 

Chapter III describes conducting and organizing the experiment, including the 
dependent measures to be used. Chapter IV is the data analyses and experimental 
results. Specifically this chapter contains descriptive statistics from the three groups and 
discusses the findings. Chapter V contains the conclusions and recommendations for 
further study. 
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n. PREPARING THE GAME INTERFACE 


A. EXPERIMENTAL DESIGN 

The Systems Dynamics Model of Software Development is a role playing 
computer based simulation game that mimics the programming phase of a real software 
development project. The participants assume the role of software project manager and 
make resource allocation decisions to complete the project on time and within schedule. 
The software project manager makes staff allocation decisions including the total number 
of staff and the percent of staff allocated to quality assurance. The project managers also 
provide their estimates of cost and schedule throughout the project at each of the 40 day 
intervals. 

The project begins with a core team of four. These software professionals 
provide the continuity between the requirements/design phase and the programming 
phase. The project managers initially receive estimates of the size of the system in 
delivered source instructions, cost of the programming phase in person days, and 
duration of the programming phase in days. Every two month interval, 40 working days, 
the model generates status information on the projects’ progress. At the end of the 
period and after reviewing these reports and graphs, the project manager is able to make 
adjustments to the staffing level and its allocation. 

The research question is to determine the effects of risk in terms of staff turnover 
on software project management. The 41 students were randomly assigned to three 
groups [Ref. 12]. The randomization worksheet is contained in Appendix P. All three 
groups interacted with projA.dnx. The source code is available in Appendix J. The 
three groups were the uncertainty group, the risk group, and the certainty group. 

B. THE THREE GROUPS 

The software program managers of the uncertainty group (Al) did not receive any 
probability information about staff turnover. The risk group (A2) managers were told 
that historically the turnover rate averages to 1.5 people lost every reporting period. The 
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certainty group (Bl) managers were notified in advance about personnel intending to 
leave the project during the next 40 day period. The number of staff lost due to turnover 
experienced in a period was determined in advance and designed into the simulation at 
the onset. The project was created using data collected from an actual NASA 
development effort. 

C. THE SOFTWARE 

The students for this experiment had participated in an experimental investigation 
of the impact of goals on software project development six months earlier. First, part 
of the feedback from that experiment included a request to capture cumulative 
information on project status from several periods and make it available to the project 
manager. To incorporate this change, a new report, the Project Cumulative Report, was 
created. It is a report specification file that captures the values of variables in different 
periods and displays them to the user. This file is written in Dynamo Plus and is 
displayed in Appendix A. 

Two other new dynamo report specification (.drs) files are contained in 
Appendices B and C. These files are the staff loss notices for the project. These files 
were created to display staff turnover information to the project managers of the three 
groups. The project managers for the uncertainty and risk groups used the project A 
batch control file while the managers for the certainty group used the project B batch 
control file. 

During execution of the batch control files, the Staff Loss Report Specification 
and the Planned Loss Report Specification programs are called and allow for the 
information contained in them to be displayed. A sample of the report shown to the 
managers of the certainty group is contained in Appendix D. This report flashes on the 
screen and notifies the project manager of personnel leaving within the next 40 days. 
For the participants of the uncertainty and risk groups the report differs in that it flashes 
on the screen the total number of personnel lost in the previous period. This staff loss 
notice is displayed in Appendix F. 
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Figure 2-1 Number of Staff Losses Per 40 Day Time Period 


Figure 2-1 displays the number of people lost due to turnover in each of the 40 
day periods throughout the project. For example at time 120, project managers of the 
certainty group would receive a staff loss notice telling them that 2 people intend to leave 
the project within the next 40 days. The same is not true for managers in the risk and 
uncertainty groups. However during time 160 these two groups would be notified that 
the project lost two people due to turnover. 

A menu capability for accessing multiple reports and graphs was developed in an 
earlier research effort along with a detailed description of module interaction for the 
simulation [Ref. 13]. The Project Staffing Report was modified to provide additional 
information for this project. Two output variables were created to report the total staff 
at the beginning of the period and the total staff hired in the period. This information 
was provided to the project manager to clarify what staffing changes had occurred. The 
report includes the total staff size, the percent of workforce experienced as of a particular 
day in the programming phase, and is displayed in Appendix E. 

Another dynamo report specification was developed for this experiment. A 
progress.drs file was created to flash the current period prior to any loss notices being 
displayed. This progress report specification is contained in Appendix G. The report 
specifications for the graphs were also changed. These changes are summarized in 
Appendix O. Coding was added to the batch control files to allow these reports to be 
displayed to the user. These batch control files are contained in Appendices H and I. 
Having completed the software, the documentation was developed to provide the details 
of the experiment to the users. 
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D. THE DOCUMENTATION 

A written description of the simulation interface, the menu, the reports, and the 
graphs available to the project managers is contained in Appendix E. The menu allows 
the project manager to select the report or graph to be viewed. These can be viewed 
repeatedly. An option at the bottom of the menu allows the user to proceed with the 
simulation. 

The first report is the Project Status Report. This report shows the initial 
estimates for the project, updated estimates entered by the project manager, and reported 
progress on the project. This information is also contained in the Project Cumulative 
Report. This report aggregates the information from the start of the project to the 
current period. When the percent DSI reaches 100, the simulation is complete. 

The Staffing Report provides the current total staff size and the allocation of staff 
between programming and quality assurance. The report reflects any changes in the 
staffing level hired or lost and provides the program manager with the percent of 
workforce that is experienced. A trained staff member is twice as productive as a new 
hire. A Defect Report details the total defects detected and the defect density for the 
current period and for the last 40 days. 

Additional documentation was provided. Each project manager received an 
instruction set. Appendices K-M. The group instruction sets were different. Duplicate 
information includes the rules of the game, instructions for starting the system, and initial 
project estimates. 

Project managers were told that for modest additions in staffing, the average 
hiring delay is 40 days. Requests for a large number of additional staff will cause longer 
delays and these new hires must be trained and assimilated. The assimilation period is 
typically 80 days. Project managers were also given information about the possibility 
of losing people due to turnover. Lastly, they were given a goal to minimize both cost 
and schedule. 
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E. TRIAL EXPERIMENT 


The purpose of the trial experiment was to find problems with either the software 
or the documentation. Two people participated in the trial experiment. These were the 
same people designated as lab attendants in the actual experiment. This was an 
opportunity to gain feedback on the experiments’ design. Neither student experienced 
any difficulty in the trial run. 

F. FINAL PREPARATIONS 

Two labs were reserved for conducting the experiment. Each student received 
an envelope containing a description of the simulation interface, an instruction set, a 
seating chart, and a disk. The disk contained the files for running the experiment. 

All copies of the documentation and the files were made corresponding to the 
random assignment of personnel into the three groups conducted earlier. The 
randomization worksheet is contained in Appendix P. The terminals in the labs were 
checked prior to assigning personnel. Signs were posted on the labs during the 
experiment to prevent other students from entering. The remaining task was to assemble 
the envelope contents. 
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m. CONDUCTING THE EXPERIMENT 


A. TASKS AND PROJECT CHARACTERISTICS 

The students for the experiment received a 40 minute briefing on the 
documentation for the experiment and a review of the terminology present in the reports. 
They proceeded to the labs to conduct a practice experiment. Each student was given 
a folder containing a description of the simulation interface, an instruction set, a seating 
chart, and a disk. The students were instructed that their level of effort on the simulation 
would be reflected in their class participation grade. 

The practice instruction set is displayed in Appendix N. Seating charts were 
developed and were the same for both the practice and the actual experiment. The goal 
for the practice experiment was for the students to familiarize themselves with the 
simulation environment. The inial estimates for the practice project remained constant 
and no personnel turnovers occurred. 

The instruction set for the practice experiment was similar to that of the other 
instruction sets except that it lacked any information on the project risk, that of losing 
people due to turnover. The students conducted the practice experiment in 30 minutes. 
Each student had the opportunity to make staffing allocation decisions, review reports 
and graphs, and ask questions. The lab attendants received a 15 minute briefing to 
ensure questions asked were answered consistently. The designer frequently moved 
between the labs during the practice experiment. 

B. THE EXPERIMENTAL SUBJECTS 

Project managers for this experiment were graduate students in their seventh 
quarter of an eight quarter program in Information Technology Management at the Naval 
Postgraduate School. They have taken courses in software engineering, participated in 
a similar experiment six months earlier, and have practical managerial experience. These 
students participated in the actual experiment two days after conducting the practice 
experiment. 


11 



Before proceeding to the labs to conduct the actual experiment, the students 
received a ten minute briefing on project risk. Mentioned were the primary sources of 
risk including personnel shortfalls, unrealistic cost/schedule, and changing requirements. 

In the actual experiment, the project is originally underestimated. The project 
grows from the original estimate of 42,000 DSI to 64,000 DSI. Students are briefed that 
the simulation ends when the reported percent DSI complete reaches 100. 

C. DEPENDENT MEASURES 

At project completion ten performance variables are captured. These variables 
are dependent upon the decisions made by the project manager throughout the 
experiment. An explanation of these performance variables can be found in Appendix 
Q. Three of these performance variables are final cost, final cumulative time, and final 
errors remaining undetected. These variables are compared to determine differing or 
similar project outcomes between the three groups; uncertainty, risk, and certainty. 

Final cost is measured in person days and final cumulative time is measured in 
days. Final errors remaining undetected is a measure used to determine the quality of 
the software. These three performance variables are compared as part of the data 
analysis in Chapter IV. 
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IV. EXPERIMENTAL RESULTS AND ANALYSES 


A. MODEL OF ANALYSIS 

Several sets of data were captured during the simulation. These data include 
performance data, a measure of project outcome; process data, a measure of decisions 
made over time; and demographic data. The demographic data was obtained through the 
use of a questionnaire. A questionnaire was completed by each student and a sample is 
contained in Appendix R. 

The analysis of the data was conducted using the Statistical Analysis System 
(SAS) software. Procedure Means, and the Procedure General Linear Models (GLM). 
The GLM Procedure was used for multivariate analyses. The Correlation Procedure was 
used to determine correlation between independent and dependent variables. 

B. PERFORMANCE DATA 


Final cost, final schedule, and final errors are the three dependent measures used 
to evaluate performance differences among the three groups. Figure 4-1 shows means 


Group 

FNCOST, Mean 

and (Stnd Dev) 

FNSKED, Mean 

and (Stnd Dev) 

FNERR, Mean 

and (Stnd Dev) 

Uncertainty (Al) 

3333.66 

339.15 

13414.73 


(733.04) 

(54.9) 

(10470.29) 

Risk (A2) 

2941.76 

310.21 

14654.44 


(523.73) 

(43.54) 

(9912.12) 

Certainty (Bl) 

2667.01 

274.64 

11559.47 


(425.91) 

(47.49) 

(8144.78) 


Figure 4-1 Performance Means and Standard Deviations for the Groups 
and standard deviations for the three groups for the three variables mentioned. The 
certainty group had the lowest final cost, final schedule, and errors remaining. 
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The subjects of the certainty group were given advance notice of staff losses to 
occur during the next 40 day period. The group with the most risk, the uncertainty 
group, had the highest mean final cost and schedule. The risk group participants, given 
the probability of staff losses to occur during the next 40 day period, had the next highest 
final cost and schedule. The results indicate that the information received by the groups 
pertaining to staff turnover significantly influenced project outcome in terms of final cost 
and schedule. 

The GLM Procedure was used for comparison of the groups’ performance to 
determine if there were significant differences between the groups. For final cost, the 
GLM yielded a p value of 0.0187. This rejects the null hypothesis of no differences 
between the groups in terms of final cost. This result indicates that for final cost there 
were significant differences between the three experimental groups. 

For final schedule the GLM produced a p value of 0.0066. Again, the null 
hypothesis is rejected and this result indicates that there were significant differences 
between the three groups in terms of schedule. The GLM Procedure for final errors 
revealed a p value of 0.7182. The null hypothesis is accepted that there was no 
significant difference between the three groups in terms of final errors. 

C. PROCESS DATA 

The subjects made four decisions in each period. At each 40 day interval the 
project managers selected their total staff, percentage of staff allocated to quality 
assurance, and estimates of the projects’ final cost and schedule. The process data was 
analyzed to compare group means at each 40 day interval. In graphing the group means 
for the process data obtained, the last interval used is day 200. This is the last period 
in which all participants were still making decisions and had not completed the project. 
An analysis using the SAS GLM procedure was conducted to first determine if there was 
a period effect, second to determine any time effect between the different risk groups, 
and thirdly to determine if there was significant difference between subjects of the three 
groups. 
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Figure 4-2 Mean Total Staff Requested by Group 

1. Total Staff 

Figure 4-2 is a graph of the group means for the total staff requested by each 
group at each 40 day interval. The graph reveals that for total staff the uncertainty group 
and the risk group made similar decisions. These project managers received notice of 
a staff turnover after it had occurred. The first staff loss occurred at day 40. 

The decisions made by the project managers of the certainty group are different. 
These project managers were notified at day 40 that three people intended to leave during 
the next 40 day period due to turnover. It can be seen that the certainty group staff 
decisions’ increase and decrease earlier than the other groups. 

The analysis for a period effect yielded a p value of 0.0001. This allows the null 
hypothesis of no period effect to be rejected. There is a period effect. The test for 
interaction between the groups yielded a p value of 0.0001. Again, the null hypothesis 
of no interaction is rejected. The test for between subject effects yielded a p value of 
0.1925. The null hypothesis is accepted that the subjects’ decisions toward staffing are 
not significantly different. 
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Figure 4-3 Percent of Requested Staff Allocated to QA by Group 

2. Quality Assurance 

Above is Figure 4-3, the percent of staff allocated to quality assurance by group. 
This graph depicts that there is a period effect. Both the uncertainty group and the risk 
group had their percent staff allocated to quality assurance decline while the certainty 
group had an initial increase in staff assigned to quality assurance. This can be explained 
by a shift in personnel from quality assurance to programming as staff turnovers 
occurred. 

The test for a period effect yielded a p value of 0.0001. The null hypothesis of 
no period effect is rejected. The test for interaction between groups yielded a p value 
of 0.0078. The null hypothesis of no interaction is rejected. For the between subjects 
effects test, the p value was 0.7630. The null hypothesis of no significant difference 
between subjects is accepted. 






Figure 4-4 Estimates of Project Final Cost by Group 

3. Cost Estimates 

The project mean cost estimates by group are shown in Figure 4-4. All three 
groups had cost estimates that continually increased. This can be explained by the 
growth in project size from its initial estimate of 42,000 DSI to 64,000 DSI. Again the 
graph shows that there is a period effect. 

The test for a period effect revealed a p value of 0.0001 indicating that there is 
a period effect and the null hypothesis is rejected. The test for interaction yielded a p 
value of 0.1751. The null hypothesis of no interaction is accepted. For the between 
subjects effects the p value was 0.1219. The null hypothesis of no between subjects 
effect is accepted. 


17 





Figure 4-5 Estimates of Project Final Schedule by Group 

4. Schedule Estimates 

Figure 4-5 represents the project final schedule estimates by group. The graph 
depicts a period effect. All three groups also had increasing estimates for the final 
schedule. Again, this can be explained by the fact that the project increased in size from 
the initial estimates. 

With a p value of 0.0001, the null hypothesis of no period effect is rejected. The 
test for interaction revealed a p value of 0.0857. The null hypothesis of no interaction 
is accepted. The test for between subjects effects yielded a p value of 0.0848. The null 
hypothesis of no between subjects effect is accepted. 
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D. QUESTIONNAIRE AND DEMOGRAPHIC DATA 


At project completion each participant filled out a questionnaire. The final section 
of the questionnaire was dedicated to demographics. The demographic data format can 
be found in Appendix S and sample data for all the subjects is in Appendix T. 


Group 

AGE 

CHRSWK 

WKEXP 

EDAGO 

Uncertainty 

34.9 

28.1 

14.3 

13.3 

Risk 

34.5 

15.8 

12.6 

10.8 

Certainty 

32.8 

20.6 

10.8 

9.4 


Figure 4-6 Group Mean Demographics 


Figure 4-6 represents the sample profile by group. CHRSWK represents the 
number of hours spent on the computer per week, WKEXP represents the years of work 
experience, and EDAGO is the number of years since the subject completed 
undergraduate education. The uncertainty group subjects have the highest mean age, 
have more work experience, and spend the most hours per week on the computer. The 
risk group subjects spend the least amount of time on the computer per week. The 
certainty group subjects are the youngest with the least amount of work experience and 
have most recently completed their undergraduate education. 
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V. CONCLUSIONS 


A. FINDINGS AND IMPLICATIONS 

The results of this experimental investigation into the effects of risk on dynamic 
decision making in a software project environment reveal that the presence of risk 
significantly impacts project outcome. The uncertainty group, the group receiving the 
least information about staff turnover, had a higher final cost and schedule at project 
completion. The risk group had the next highest final cost and schedule. The certainty 
group, which were informed about staff departures prior to their occurrence, performed 
better than the other two groups. 

The analysis of the process data which was concerned with the mean performance 
of the groups over time, revealed that the groups perform significantly different. This 
is especially visible in the graphical depictions of total staffing and quality assurance 
allocation decisions. 

The certainty group once informed that a staff loss was to occur, padded the 
staffing level in anticipation of the loss while the other two groups responded with 
additional hires immediately following the loss. This perceived risk had an impact on 
their decision making. In addition the risk group subjects shifted their staffing resources 
from quality assurance to programming following the initial loss of personnel. 

This research effort provides empirical findings that support the assessment and 
management of risk as significant factors in achieving successful project outcome. The 
greater the risk the greater the cost and schedule overrun. Additionally, this research 
effort seeks to provide impetus toward investigation of other human behavioral decision 
making characteristics found in the software project development domain. 
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B. FURTHER RESEARCH 


One area with potential for further research is to investigate the impact of risk on 
team decision making. This experiment could be repeated with teams managing the 
project rather than single individuals. This would provide insight into team management 
of risk and the communication required. It is likely that that the groups would identify 
and deal with risk differently. Finally, this research could be duplicated in a multi¬ 
project environment. 
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APPENDIX A: PROJECT CUMULATIVE REPORT SPECIFICATION 


report 

time = maxtime, 

F0RMAT="5<" 

••>>>>>>>>>>>>>>>>>>> PROJECT CUMULATIVE REPORT 
<<<<<<<<<<<<<<<<<<<<<<<<<<"; 

Format="5<,43<" 

"UPDATED ESTIMATES","REPORTED PROGRESS"; 

Format="5 < ,13 < ,20< ,26< ,31 < ,43 < ,49 < ,58 < ,72 >," 

"TIME","SIZE", "COST", "DUR","TIMREM"," %DSI", "TOT DSI", "PD 
EXP’D","PROD"; 

FOR TIME = 40 TO MAXTIME BY 40 DO 
Format="2<,10<,17<,22<,30<,40<,49<,59<,72>", 

PICTURE ="ZZZ ZZ9V" 

TIME,PJBSZT,JBSZMD,SCHCDT,TIMERM,PRCMPL,CMDSI,CUMMD,RPPROD 

END 


"PRESS < ENTER > TO RETURN TO THE MENU" 
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APPENDIX B: STAFF LOSS REPORT SPECIFICATION 


report 

time=maxtime, 

if maxtime <41 then 
FORMAT="15<" 

It 5|c 3|c Jlc ♦ JK :|e :|c 5|e 5|« ;|c * jjc 3|c 3|e :|e 5|c 3|e :|c ♦ ♦ 3k 3|e :ic :jc ♦♦ ** 3je . 

> 

FORMAT="15<,67<" 

ii3k« »3|e»< 

FORMAT=" 15 < ,28 < ,67 <" 

"Press <ENTER> to continue.","*"; 
FORMAT="15<,67<" 

ti3ki' Htk*'* 

FORMAT="15<" 

•i3k3ic3K9|eJ|«3lc3|e*3Ks|es*ei|e*5|«3|c3|f***3k:|es|«s»e*ak3|e*5|c***3K5!c**9l«**Jl«*5l«*****5*e**5l«’lf**” j 

end 

if maxtime >41 then 
if maxtime <81 then 
FORMAT="15<" 

It 3|C * He ♦*** 3jc * 5K 3 !c 5|C 3k ** 5k **♦♦*♦♦♦* 5k *♦♦***♦* ate ********* • 

3 

FORMAT=" 15 <,67 <" 

iisk*! n*«i. 

FORMAT=" 15 < ,28 < ,67 <" 

"*","!! STAFF LOSS NOTICE !!","*"; 

FORMAT=" 15 <,67 <" 

11*11 «*H. 

FOmAT="15 < ,29< ,42< ,48< ,67< ",PICTURE="Z,ZZ9V" 
"*","[Current TIME =",TM,"DAYS]","*"; 

FORMAT=" 15 <,67 <" 

II *H 11*11. 

FORMAT="15 < ,21 < ,67<" 

"♦" "During the last 40 day Period, the project","*"; 

FORMAT=" 15 < ,21 < ,22 < ,28 < ,67 <" 

"*","lost",WFLOSA,"people due to turnover.","*"; 

FORMAT=" 15 <,67 <" 

It *11 11*11. 

3 3 
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FORMAT=" 15 <,67 <" 

FORMAT=" 15 < ,28 < ,67 <" 

"Press <ENTER> to continue.","*"; 

FORMAT=" 15 <,67 <" 

FORMAT="15<" 

end 

end 

if maxtime >81 then 
if maxtime < 121 then 
FORMAT="15<" 

n;^:^^^***************************************************”; 
FORMAT=" 15 <,67 <" 

li*ti iijicft. 

FORMAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 

FORMAT=" 15 <,67 <" 

FORMAT=" 15 <" 

"♦♦♦sit**********************************************''***"; 

end 

end 

if maxtime > 121 then 
if maxtime <401 then 
FORMAT="15<" 

»*****************************************************"; 

FORMAT="15<,67<" 

FORMAT=" 15 < ,28 < ,67 <" 

"*","!! STAFF LOSS NOTICE 
FORMAT=" 15 <,67 <" 

FORMAT=" 15 < ,29 < ,42 < ,48 < ,67 < ",PICTURE="Z,ZZ9V" 
"*","Current TIME =",TM,"DAYS","*"; 
FORMAT="15<,67<" 

FORMAT="15 < ,21 < ,67 <" 

"*","During the last 40 day Period, the project","*"; 
FORMAT="15 < ,21 < ,22< ,28 < ,67 < " 
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"lost",WFLOSA,"people due to turnover.","*"; 

FORMAT=" 15 <,67 <" 

FORMAT="15<,67<" 

FORMAT=" 15 < ,28 < ,67 < " 

"Press <ENTER> to continue.","*"; 
FORMAT="15<,67<" 

FORMAT="15<" 

II 3|c 3*e 5|s j|e 3|c ♦ j|e 9|e s|e 5|c 3|c :|e * 5|c 3|e 5lc * 9tc aic :|e * 3|e :jc j|c Jlc 3|c * 3lc * 3|e ale Jlc * :i|c 3lc H . 

end 

end 

if maxtime >401 then 
if maxtime<441 then 

FORMAT="15<" 

Il:lc5lc9|cs(c:|6*5ic^5|esf:^:lc:(c:ic*3(cs!e:lc:|c**:(c:ic*:|c:te5|«3!c**3|c3|c3|c*s|c*9l«3lc3le***3lc*5|<********" j 

FORMAT="15<,67<" 

iiaieii ll9ti*’> 

FORMAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 
FORMAT="15<,67<" 

M*ll 11*11. 

FORMAT="15<" 

«***************************************************♦♦”• 

9 

end 

end 

if maxtime >441 then 
FORMAT="15<" 

ii************************:t(**********:fe9|c*3H)|ea)e3(e**9)c********** • 

9 

FORMAT=" 15 <,67 <" 

11*11 11*11. 

FORMAT=" 15 < ,28 < ,67 < " 

"*","!! STAFF LOSS NOTICE !!","*"; 

FORMAT="15<,67<" 

•1*11 11*11. 

FORMAT=" 15 < ,29 < ,42 < ,48 < ,67 < ",PICTURE="Z,ZZ9V" 
"*","Current TIME =",TM,"DAYS","*"; 
FORMAT="15<,67<" 

11*11 l»*l». 

9 9 
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FORMAT=" 15 < ,21 < ,67 <" 

"During the last 40 day Period, the project","*"; 
FORMAT=" 15 < ,21 < ,22 < ,28 < ,67 < " 

"*","lost",WFLOSA,"people due to turnover.","*"; 
FORMAT=" 15 <,67 <" 

FORMAT=" 15 <,67 <" 

FORMAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 
FORMAT=" 15 <,67 <" 

FOmAT="15<" 

end 

if maxtime >481 then 
FORMAT=" 15 <" 

FORMAT=" 15 <,67 <" 

ii*it «*«. 

FOmAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 
FORMAT=" 15 <,67 <" 

FOmAT="15<" 

end 
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APPENDIX C: PLANNED LOSS REPORT SPECIFICATION 


report 

time=maxtime, 

if maxtime <41 then 
F0RMAT="15<" 

11 j|e 5 !c 3|c 5|6 5ic * aje ♦♦*** 3|c sic **♦* :|« ♦**♦****♦♦****♦»•. 

FORMAT="15<,67<" 

tt:|eu tiafcH. 

FOmAT=" 15 < ,28 < ,67 <" 

STAFF LOSS NOTICE 
FORMAT="15<,67<" 

FORMAT=" 15 < ,29 < ,42 < ,48 < ,67 <" ,PICTURE="Z,ZZ9V" 

" " [Current TIME =" ,TM, "DAYS] 

FORMAT="15<,67<" 

11*11 It *11. 

FORMAT=" 15 < ,21 < ,41 < ,47 < ,67 <" 

"*","We received notice from",WFLOSB,"people that","*"; 
FORMAT=" 15 < ,21 < ,67 <" 

"*","they intend to leave the project","*"; 

FORMAT=" 15 < ,21 < ,67 <" 

"*","within the next 40 days.","*"; 

FORMAT="15<,67<" 

11*11 it*w. 

FORMAT="15<,67<" 

H*ll II *11. 

FORMAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 

FORMAT=" 15 <,67 <" 

11*11 11*11. 

FORMAT="15<" 

Ii**********************:j«*5|e3|c3|c5|e***5ics|e********3|«***********" J 

end 

if maxtime >41 then 
if maxtime <81 then 
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FORMAT="15<" 

FORMAT="15<,67<’' 

Hajeii ((9|ctt. 

FORMAT=" 15 < ,28 < ,67 <" 

"Press <ENTER> to continue.","*"; 
FORMAT="15<,67<" 

FORMAT=" 15 <" 

II*****************************************************"- 

end 

end 

if maxtime >81 then 
if maxtime <361 then 
FORMAT="15<" 

FORMAT="15<,67<" 

M:IC« «♦«. 

FORMAT=" 15 < ,28 < ,67 <" 

"*","!! STAFF LOSS NOTICE !!","*"; 

FORMAT=" 15 <,67 <" 

FORMAT=" 15 < ,29 < ,42 < ,48 < ,67 <" ,PICTURE= "Z,ZZ9V" 
"*","[Current TIME =",TM,"DAYS]","*"; 

FORMAT=" 15 <,67 <" 

FORMAT=" 15 < ,21 < ,41 < ,47 < ,67 <" 

"*","We received notice from",WFLOSB,"people that","*"; 
FORMAT=" 15 < ,21 < ,67 <" 

"*","they intend to leave the project","*"; 

FORMAT=" 15 < ,21 < ,67 <" 

"*","within the next 40 days.","*"; 

FORMAT=" 15 <,67 <" 

l(9|eH IIjicM. 

FORMAT=" 15 <,67 <” 

II ♦tf. 

FORMAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 

FORMAT=" 15 <,67 <" 

ii9|ei* ii9|cii. 

FO]mAT="15<" 

II*****************************************************" I 


30 



end 

end 

if maxtime > 361 then 
if maxtime <401 then 
FORMAT="15<" 

FORMAT="15<,67<" 

ii5|e« iijJeH, 

FORMAT=" 15 < ,28 < ,67 <" 

"Press <ENTER> to continue.","*"; 
FORMAT="15<,67<" 

FORMAT="15<" 

«*♦♦*♦*♦♦♦#**♦*****♦*♦♦♦♦******♦*♦*******♦***♦***♦****" 

end 

end 

if maxtime >401 then 
if maxtime<441 then 
FORMAT="15<" 

FORMAT="15<,67<" 

flsfctt Illicit. 

F0IUV1AT=" 15 < ,28 < ,67 <" 

"*","!! STAFF LOSS NOTICE !!","*"; 

FORMAT=" 15 <,67 <" 

iisietf. 

FOmAT=" 15 < ,29 < ,42 < ,48 < ,67 <" ,PICTURE= "Z,ZZ9V" 
"*","[Current TIME =",TM,"DAYS]","*"; 

FORMAT=" 15 <,67 <" 

FORMAT=" 15 < ,21 < ,41 < ,47 < ,67 <" 

"♦" "We received notice from",WFLOSB,"people that","*"; 
FORMAT=" 15 < ,21 < ,67 <" 

"*","they intend to leave the project","*"; 

FORMAT=" 15 < ,21 < ,67 <" 

"*","within the next 40 days.","*"; 

FORMAT="15<,67<" 

FORMAT="15<,67<" 

Mjtcll 11*11. 

FORMAT=" 15 < ,28 < ,67 <" 
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"Press <ENTER> to continue.","*"; 

FORMAT="15 <,67 <" 

FOmAT=’T5<" 

«***1|C»******»***»*»*****#**»*****>I'»***»***»*******»***" 

end 

end 

if maxtime >441 then 
FORMAT='T5<" 

II ♦#♦♦♦*♦*♦»****»**♦♦♦**********************♦**********" 

FORMAT="15 <,67 <" 

FORMAT=" 15 < ,28 < ,67 <" 

"*","Press <ENTER> to continue.","*"; 

FORMAT=" 15 <,67 <" 

II ii)|cti. 

FORMAT=" 15 <" 
end 
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APPENDIX D: PLANNED LOSS OUTPUT 


* 

* 11 STAFF LOSS NOTICE I 1 

* 

* [Current TIME =120 DAYS] 

* 

* We received notice from 2 people that 

* they intend to leave the project 

* within the next 40 days. 

* 

* 

* Press <ENTER> to continue. 

* 


* 

* 

★ 

* 

* 

* 

★ 

* 

* 

* 

* 
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APPENDIX E: DESCRIPTION OF THE SINUIiATION INTERFACE 


REPORTS AND GRAPHS MENU: 

After every 40-day simulation period, you will immediately get the 
Reports and Graphs Menu shown below. All of the reports and graphs 
concerning your project's progress are available from this menu. You 
may select any of them by pressing their corresponding number. 




REPORTS AND GRAPHS MENU 1 - j 

REPORTS: 


B 

PROJECT SIZE & STATUS REPORT 


2 

STAFFING REPORT 


3 

DEFECT REPORT 


4 

CUMULATIVE REPORT 

GRAPHS: 


5 

PROJECT SIZE & STATUS GRAPH 


6 

STAFFING GRAPH 


■ 

DEFECT GRAPH 

PRESS 

P 

TO PROCEED TO ENTER DECISIONS FOR THE NEXT 40 DAYS 


After viewing the pertinent information (you may view any report or graph more than 
once), use the "P" selection to proceed to enter your decisions for the next 40 day simulation 
period. 
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Report 1 (PROJECT STATUS REPORT) A sample report is pictured below: 


PROJECT STATUS REPORT 


AT TIME = 


120 DAYS 


INITIAL ESTIMATES: (These will not change throughout the project) 

System Size 20,000 DSI 

Programming Cost 1.400 Person Days 

Programming Phase Duration (start-end) 350 Days 


UPDATED ESTIMATES 

New Est of System Size 

due to Changes in Requirements 20,000 

Your Last Est of Programming Phase Cost 1,567 

Your Last Est of Prog Phase Duration (start-end)353 
Time Remaining 1^^ 

REPORTED PROGRESS 

% DSI Reported Complete 63.33 

Total DSI Reported Complete to Date 12,665 

Total Person Days Expended to Date 817 

Reported Productivity 16 


DSI 

Person Days 

Days 

Days 

Percent 

DSI 

Person Days 
DSI/Person Day 


PRESS <ENTER> TO RETURN TO THE MENU 


This report contains Project Status information as of a particular day in the 
programming phase. The report is divided into 3 sections. The top section shows the 
INITIAL ESTIMATES provided to your customer. This information will not change 
throughout the project. 

The middle portion is the UPDATED ESTIMATES section. The Updated Est of 
System Size can change (increase or decrease) to reflect the addition or deletion of 
requirements. The entries of Your Last Est of Programming Hiase Cost and Your Last 
Est of Prog Hiase Duration (start-end) would reflect any change in cost and duration that 
you feel you need to make. The Time Remaining is equal to your current estimate of total 
duration minus current time. 

The bottom section is the REPORTED PROGRESS section. Remember that this is 
"reported" information and is not guaranteed to be totally accurate, especially early in the 
phase. Reported Productivity is simply calculated as Total DSI Reported Complete to 
Date divided by Total Person Days Expended to Date. 

Your Task is complete when the % DSI Reported Complete is 100%. 
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Report 2 (STAFFING LEVEL REPORT) A sample report is pictured below: 


STAFFING REPORT 
AT TIME = 160 DAYS 


STAFFING ADDITIONS/LOSSES LAST 40 DAY PERIOD ONLY 
Total Staff At Beginning of Period 
Total Staff Hired this Period 
Total Staff Lost this Period 

Current Total Staff Size 

STAFF ALLOCATION 

Staff Allocated to Programming 
Staff Allocated to QA 

Current Total Staff Size 

Percent of Workforce that is Experienced 

PRESS <ENTER> TO RETURN TO THE MENU 


7.21 

People 

2.49 

People 

2.00 

People 

7.69 

People 

6.92 

People 

.77 

People 

7.69 

People 

43 

Percent 


This report contains staffing information as of a particular day in the programming 
phase. The Current Total Staff Size consists of your total staff allocated to both 
programming activities and QA activities. It is the sum of Staff Allocated to 
Progr ammin g and Staff Allocated to QA. 

The Percent of Workforce that is Experienced is also shown on this report. This is 
the number of experienced people (i.e. already trained/assimilated) divided by the total staff 
size (which is the sum of experienced and new staff). As mentioned above, once new people 
are hired, they go through an assimilation/training period. This is the time needed to train a 
new employee in the mechanics of the project and bring him/her up to speed. A new 
employee (i.e. one that is being trained) is only half as productive as an experienced 
employee. 
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Report 3 (DEFECT REPORT) A sample report is pictured below: 


DEFECT REPORT 


CXJMULATIVE STATUS FROM START OF PROJECT TO CURRENT DAY => 200 


TOTAL Person Days Expended to Date 
Programming Person Days Expended 
QA Person Days Expended to Date 

TOTAL Defects Detected 
TOTAL KDSI Completed 
Defect Density 

-STATISTICS FOR THE LAST 40 



817 

Person Days 

to Date 

735 

Person Days 


82 

Person Days 


137 

Defects 


12.67 

KDSI 

DAY PERIOD 

10.9 

ONLY- 

Defects/KDSI 


QA Person Days Expended Last 40 Days 
Defects Detected Last 40 Days 
Defect Density Observed Last 40 Days 


18 Person Days 

38 Defects 

11.6 Defects/KDSI 


PRESS <ENTER> TO RETURN TO THE MENU 


This report recaps the TOTAL Person Days Expended to Date and provides a 
breakdown of the number of person days expended on both the QA and programming 
activities. 

In the top section, this report gives cumulative defect data (i.e. from start of 
programming phase to current time). The bottom section shows data for the last 40 day 
period only. 

Historically, the Defect Density (i.e. number of defects detected during programming 
divided by the number of KDSI develop^) has ranged from 5-20 Defects/KDSI. 

Comparing the aggregate data and the data for the last period can indicate trends. 
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Report 4 (CUMULATIVE REPORT) A sample report is pictured below: 


PROJECT CUMULATIVE REPORT 


UPDATED ESTIMATES 


REPORTED PROGRESS 


TIME 

SIZE 

COST 

DUR 

40 

20,000 

1,400 

350 

80 

20,000 

1,400 

350 

120 

20,000 

1,400 

350 

160 

20,000 

1,400 

350 

200 

20,000 

1,400 

350 


PRESS <ENTER> TO RETURN 


TIMREM 

%DSI 

TOT DSI 

310 

7 

1,434 

270 

15 

3,020 

230 

25 

5,092 

190 

38 

7,587 

150 

52 

10,483 


THE MENU 


PD EXP'D 
78 
199 
366 
550 
738 


PROD 

18 

15 

14 

14 

14 


This report contains Cumulative Project Status information from the start of the 
project to the current period. The report is divided into 2 sections. 

The left portion is the UPDATED ESTIMATES section. It reflects cumulative 
changes in the following project estimates: 

SIZE New Estimate of System Size due to changes in Requirements 

(DSI) 

COST Your Last Est of Programming Phase Cost (Person Days) 

DUR Your Last Est of Prog Phase Duration (start-end) (Days) 

TIMREM Time Remaining (Days) 

The right portion is the REPORTED PROGRESS section. Remember that this is 
"reported" information and is not guaranteed to be totally accurate, especially early in the 
phase. It reflects cumulative changes in the following project estimates: 

%DSI %DSI Reported Complete (Percent) 

TOT DSI Total DSI Reported Complete to Date (DSI) 

PD EXP’D Total Person Days Expended to Date (Person Days) 

PROD Reported Productivity (DSI/Person Day) 

Your Task is complete when the % DSI is 100%. 
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Graph 5 (PROJECT STATUS GRAPH) 

This graph shows how the total staff level and the estimates of system size and 
programming cost are changing over time. 

Graph 6 (STAFFING GRAPH) 

This graph shows how the level of the total staff, programming staff, and QA staff is 
changing over time. 

Graph 7 (DEFECT GRAPH) 

This graph shows how "QA person days expended per period" and the "number of 
defects detected per period" are changing over time. 
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APPENDIX F: STAFF LOSS OUTPUT 


!1 STAFF LOSS NOTICE !1 

Current TIME = 160 DAYS 

During the last 40 day Period, the project 
lost 2 people due to turnover. 

Press <ENTER> to continue. 


* 

* 

* 

* 

★ 

★ 

* 

* 

* 

* 
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APPENDIX G: PROGRESS REPORT SPECIFICATION 


report 

time=maxtime, 
FORMAT*"15<" 


FORMAT*"15<,67<" 

M * n ^ M * 11 . 

FORMAT="15<,21<,67<" 

"*","The model has simulated a 40 day period.","*"; 
FORMAT="15<,67<" 

II * II ^ II * II . 

FORMAT*"15<,29<,42<,48<,67<",PICTURE*"Z,ZZ9V" 

[Current TIME =",TM,"DAYS]","*"; 

FORMAT*"15<,67<" 

I * w I * J 

FORMAT*"15<,28<,67<" 

II * 11 ^ "Press <ENTER> to continue 
FORMAT*"15<,67<" 

II * II ^ 

FORMAT="15<" 

»•*****************************************************”; 
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APPENDIX H: BATCH CONTROL FILE (PROJECTA) 

©echo off 

rem PROJA initially underestimated project 
els 

rem init.exe requires 3 parameters i,e. [project,group,ins.set] 

init All 

graphics 

bat /n /p /s 

ram 

smlt PROJA -go = -prs = -Is -ns -plm 16 

rep PROJA*RSL PROCESS.DRS -outf PROCESS.OUT -t >NUL 

rep PROJA.RSL PROCESS.DRS -outf PROCESSS.OUT -t >NUL 


-top dynex PROJA -in PROJA.STT -sc -Is -plm 16 
smlt PROJA -gm = -ns -plm 16 


copy process.out process.old >NUL 

rep PROJA.RSL PROCESS.DRS -outf PROCESS.OUT -t >NUL 
rep PROJA.RSL PROCESS.DRS -outf PROCESSS.OUT >NUL 
rep PROJA.RSL INTERVAL.DRS -outf INTERVAL.OUT -t >NUL 
process 


call -topi 

rep PROJA.RSL PERFORM.DRS -outf PERFORM.OUT -t >NUL 

perform 

rem finish 

exit 


-topi els 


-PROGREP **** VIEW PROGRESS ********************************* 
timestmp 

rep PROJA PROGRESS.DRS -outf PROGRESS.OUT -t -SC -Is -plm 16 
inkey 

capture R5 >NUL 
els 

color \1F 


-STAFLOSS ***** VIEW STAFFING LOSS REPORT ******************** 
timestmp 

rep PROJA STAFLOSS.DRS -outf STAFLOSS.OUT -t -sc -Is -plm 16 
inkey 

capture R6 >NUL 
els 

color \1F 


-menu 

color \1F 
els 

begtype 
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REPORTS AND GRAPHS MENU 


\1EREP0RTS:\1F 

\1E 1 \1F 

\1E 2 \1F 

\1E 3 \1F 

\1E 4 \1F 
\1BGRAPHS: \1F 

\1B 5 \1F 

\1B 6 \1F 

\1B 7 \1F 


PROJECT SIZE & STATUS \1EREP0RT\1F 

STAFFING \1EREP0RT\1F 

DEFECT \1EREP0RT\1F 

CUMULATIVE \1EREP0RT\1F 

PROJECT SIZE & STATUS \1BGRAPH\1F 

STAFFING \1BGRAPH\1F 

DEFECT \1BGRAPH\1F 


PRESS\ID P \1F TO \lDPROCEED\lF TO ENTER DECISIONS FOR THE NEXT 40 DAYS 


Choose an option: (Do NOT hit <ENTER> after selection!!!) 
end 


Istkeyl 

. inkey 

%2 j 

type %2; 

if 

%2 

= 

1 

goto 

-STATREP 

if 

%2 


2 

goto 

-STAFREP 

if 

%2 

= 

3 

goto 

-DEFREP 

if 

%2 

= 

4 

goto 

-CUMREP 

if 

%2 


5 

goto 

-STATPLOT 

if 

%2 

= 

6 

goto 

-STAFPLOT 

if 

%2 

= 

7 

goto 

-DEFPLOT 

if 

%2 


P 

goto 

-proceed 

if 

%2 

=r 

KEYOll 

return 


beep goto -menu 


-STATREP **** VIEW PROJECT STATUS REPORT ******************** 
timestmp 

rep PROJA STATUS.DRS -outf STATUS.OUT -t -sc -Is -plm 16 
inkey 

capture R1 >NUL 
els 

color \1F 
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r 


goto -menu 


-STAFREP **** VIEW STAFFING REPORT ******************** 
timestmp 

rep PROJA STAFFING.DRS -outf STAFFING.OUT -t -sc -Is -plm 16 
inkey 

capture R2 >NUL 
els 

color \1F 
goto -menu 


-DEFREP **** VIEW DEFECT REPORT ******************** 
timestmp 

rep PROJA DEF.DRS -OUtf DEF.OUT -t -SC -Is -plm 16 
inkey 

capture R3 >NUL 
els 

color \1F 
goto -menu 

-CUMREP **** VIEW PROJECT CUMULATIVE REPORT ******************** 
timestmp 

rep PROJA CUM.DRS -outf CUM.OUT -t -sc -Is -plm 16 
inkey 

capture R4 >NUL 
els 

color \1F 
goto -menu 


-STATPLOT **** VIEW PROJECT STATUS PLOT **** 
timestmp 
els 

color \1F 
begtype 


******************************************************************************* 

* 

\1A PROJECT STATUS VARIABLES \1F 

******************************************************************************* 

THE FOLLOWING PROJECT STATUS VARIABLES WILL BE PLOTTED: 
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TOTAL STAFF. 

EST SYSTEM SIZE. 

EST PROGRAMMING COST . . 


TOTAL STAFF LEVEL 

CURRENT ESTIMATE OF SYSTEM SIZE (KDSI) 

CURRENT ESTIMATE OF PROGRAMMING COST (Person Days) 


\1A 


AFTER VIEWING PLOT PRESS <ESC> TO RETURN TO THE MENU \1F 


\1A PRESS <ENTER> TO VIEW PLOT \1F 


end 

inkey 

els 

rep PROJA STATPLOT.DRS 
capture G5 >NUL 
color \1F 
els 

goto -menu 


-STAFPLOT **** VIEW GRAPHIC STAFFING PLOT **** 
timestmp 
els 

color \1F 
begtype 


********* 

* 

\1A 

********* 


********************************************************************** 

STAFFING VARIABLES \1F 

********************************************************************** 


THE FOLLOWING STAFFING VARIABLES WILL BE PLOTTED: 


TOTAL STAFF 
QA STAFF. . 
PROG STAFF. 


TOTAL STAFF LEVEL 

NUMBER OF PERSONS ALLOCATED TO QA 
NUMBER OF PERSONS DOING PROGRAMMING 
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\1A AFTER VIEWING PLOT PRESS <ESC> TO CONTINUE \1F 


\1A PRESS <ENTER> TO VIEW PLOT \1F 


end 

inkey 

els 

rep PROJA STAFPLOT.DRS 
capture G6 >NUL 
color \1F 
els 

goto -menu 


-DEFPLOT **** VIEW DEFECT PLOT **** 
timestmp 
els 

color \1F 
begtype 


******************************************************************************* 

* 

\1A DEFECT VARIABLES \1F 

******************************************************************************* 

THE FOLLOWING DEFECT VARIABLES WILL BE PLOTTED: 


QA PERSON DAYS PER PERIOD . . . . QA PERSON DAYS EXPENDED PER PERIOD 
DEFECTS DETECTED PER PERIOD . . . DEFECTS DETECTED PER PERIOD 


\1A AFTER VIEWING PLOT PRESS <ESC> TO RETURN TO THE MENU \1F 


\1A PRESS <ENTER> TO VIEW PLOT \1F 
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END 


inkey 

els 

rep PROJA DEFPLOT.DRS 
capture G7 >NUL 
color \1F 
els 

goto -menu 


-proceed **** PROCEED WITH NEXT SIMULATION ******************** 
cls 

color \1F 
begtype 


************************************************* 
* Press <ENTER> to continue * 

************************************************* 


end 

goto -top 


-on.error- 

if %R > 82 if %R < 90 type !! Floating Point Error !! [goto -Calc. 
Cls beep type Unexpected batch file error %R in line %L |exit 
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APPENDIX I: BATCH CONTROL FILE (PROJECTB) 


§echo off 

rem PROJA initially underestimated project 
els 

rem init.exe requires 3 parameters i.e. 

[proj ect , group,ins.set] 

init B 1 1 

graphics 

bat /n /p /s 

ram 

smlt PROJA -go = -prs = -Is -ns -plm 16 

rep PROJA.RSL PROCESS.DRS -outf PROCESS.OUT -t >NUL 

rep PROJA.RSL PROCESS.DRS -outf PROCESSS.OUT -t >NUL 


-top dynex PROJA -in PROJA.STT -sc -Is -plm 16 
smlt PROJA -gm = -ns -plm 16 

copy process.out process.old >NUL 

rep PROJA.RSL PROCESS.DRS -outf PROCESS.OUT -t >NUL 
rep PROJA.RSL PROCESS.DRS -outf PROCESSS.OUT >NUL 
rep PROJA.RSL INTERVAL.DRS -outf INTERVAL.OUT -t >NUL 
process 

call -topi 

rep PROJA.RSL PERFORM.DRS -outf PERFORM.OUT -t >NUL 

perform 

rem finish 

exit 

-topi els 


-PROGREP **** VIEW PROGRESS 
********************************* 
timestmp 

rep PROJA PROGRESS.DRS -outf PROGRESS.OUT -t -sc -Is 
-plm 16 

inkey 

capture R5 >NUL 
els 

color \1F 


-STAFLOSS ***** VIEW STAFFING LOSS REPORT 
******************** 

timestmp 

rep PROJA PLANLOSS.DRS -OUtf PLANLOSS.OUT -t -SC -Is 
-plm 16 


51 



inkey 

capture R6 >NUL 
els 

color \1F 


-menu 

color \1F 
els 

begtype 


REPORTS AND GRAPHS MENU 


\1EREP0RTS:\1F 

\1E 1 \1F PROJECT SIZE & STATUS \1EREP0RT\1F 
\1E 2 \1F STAFFING \1EREP0RT\1F 
\1E 3 \1F DEFECT \1EREP0RT\1F 

\1E 4 \1F CUMULATIVE \1EREP0RT\1F 

\1BGRAPHS: \1F ^ ^ 

\1B 5 \1F PROJECT SIZE & STATUS \1BGRAPH\1F 

\1B 6 \1F STAFFING \1BGRAPH\1F 

\1B 7 \1F DEFECT \1BGRAPH\1F 


PRESS\ID P \1F TO \1DPR0CEED\1F TO ENTER DECISIONS FOR THE NEXT 40 DAYS 


Choose an option; (Do NOT hit <ENTER> after selection!!!) ; 
end 


-Istkeyl 

. inkey 

%2 j type %2; 

if 

%2 

= 

1 

goto -STATREP 

if 

%2 


2 

goto -STAFREP 

if 

%2 

= 

3 

goto -DEFREP 

if 

%2 

= 

4 

goto -CUMREP 

if 

%2 

= 

5 

goto -STATPLOT 

if 

%2 

= 

6 

goto -STAFPLOT 

if 

%2 

= 

7 

goto -DEFPLOT 

if 

%2 

= 

P 

goto -proceed 

if 

%2 

= 

KEYOll return 

beep 1 

goto 

-menu 
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-STATREP **** VIEW PROJECT STATUS REPORT ******************** 
timestmp 

rep PROJA STATUS.DRS -outf STATUS.OUT -t -SC -Is -plm 16 
inkey 

capture R1 >NUL 
els 

color \1F 
goto -menu 


-STAFREP **** VIEW STAFFING REPORT ******************** 
timestmp 

rep PROJA STAFFING.DRS -outf STAFFING.OUT -t -sc -Is -plm 16 
inkey 

capture R2 >NUL 
els 

color \1F 
goto -menu 


-DEFREP **** VIEW DEFECT REPORT ******************** 
timestmp 

rep PROJA DEF.DRS -outf DEF.OUT -t -sc -Is -plm 16 
inkey 

capture R3 >NUL 
els 

color \1F 
goto -menu 

-CUMREP **** VIEW PROJECT CUMULATIVE REPORT ******************** 
timestmp 

rep PROJA CUM.DRS -outf CUM.OUT -t -SC -Is -plm 16 
inkey 

capture R4 >NUL 
els 

color \1F 
goto -menu 


-STATPLOT **** VIEW PROJECT STATUS PLOT **** 
timestmp 
els 

color \1F 
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begtype 


******************************************************************************* 

ic 

\1A PROJECT STATUS VARIABLES \1F 

******************************************************************************* 

THE FOLLOWING PROJECT STATUS VARIABLES WILL BE PLOTTED: 

TOTAL STAFF.TOTAL STAFF LEVEL 

EST SYSTEM SIZE.CURRENT ESTIMATE OF SYSTEM SIZE (KDSI) 

EST PROGRAMMING COST . . . CURRENT ESTIMATE OF PROGRAMMING COST (Person Days) 


AFTER VIEWING PLOT PRESS <ESC> TO RETURN TO THE MENU \1F 


PRESS <ENTER> TO VIEW PLOT \1F 


inkey 

els 

rep PROJA STATPLOT.DRS 
capture G5 >NUL 
color \1F 
els 

goto -menu 

-STAFPLOT **** VIEW GRAPHIC STAFFING PLOT **** 
timestmp 
els 

color \1F 
begtype 


******************************************************************************’ 

•k 

\1A STAFFING VARIABLES \1F 

******************************************************************************’ 


THE FOLLOWING STAFFING VARIABLES WILL BE PLOTTED: 
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TOTAL STAFF . TOTAL STAFF LEVEL 

QA STAFF.NUMBER OF PERSONS ALLOCATED TO QA 

PROG STAFF.NUMBER OF PERSONS DOING PROGRAMMING 


\1A AFTER VIEWING PLOT PRESS <ESC> TO CONTINUE \1F 


\1A PRESS <ENTER> TO VIEW PLOT \1F 


end 

inkey 

els 

rep PROJA STAFPLOT.DRS 
capture G6 >NUL 
color \1F 
els 

goto -menu 


-DEFPLOT **** VIEW DEFECT PLOT **** 
timestmp 
els 

color \1F 
begtype 

******************************************************************************* 

* 

\1A DEFECT VARIABLES \1F 

******************************************************************************* 

THE FOLLOWING DEFECT VARIABLES WILL BE PLOTTED: 


QA PERSON DAYS PER PERIOD . . . . QA PERSON DAYS EXPENDED PER PERIOD 
DEFECTS DETECTED PER PERIOD . . . DEFECTS DETECTED PER PERIOD 


\1A 


AFTER VIEWING PLOT PRESS <ESC> TO RETURN TO THE MENU \1F 
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\1A 


PRESS <ENTER> TO VIEW PLOT \1F 


END 

inkey 

els 

rep PROJA DEFPLOT.DRS 
capture G7 >NUL 
color \1F 
els 

goto -menu 


-proceed **** PROCEED WITH NEXT SIMULATION ******************** 
els 

color \1F 
begtype 


************************************************* 
* Press <ENTER> to continue * 

************************************************* 


end 

goto -top 


-on.error- 

if %R > 82 if %R < 90 type !! Floating Point Error !i [goto -Calc. 
Cls beep type Unexpected batch file error %R in line %L |exit 
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APPENDIX J: PROJECT DYNEX FILE 


if #tm<.l then 
display clear 

************************************** 

!!!! Important Points to Remember 1!!! 
************************************** 

~ You are not allowed to discuss this exercise with anyone 
other than the lab attendant. Please refrain from 
discussing this with members in the other class until they 
have completed the exercise. 

- The system will show you the size of the initial core team 
of software developers who have just completed the 
requirements/design specifications. You will then be asked 
for your desired staffing level for the programming phase. 
Then, the system will run through the first simulation time 
period (40 working days) and allow you to view various 
reports and graphs. You will then be allowed to update your 
estimates for project cost and duration and change your 
staffing levels. 

- Record your decision for each interval on the 
documentation sheet provided before proceeding to the next 
interval. 


THE LAB ATTENDANT MUST VERIFY YOUR FINAL RESULTS! 

- GOOD LUCK! Press <ENTER> to continue. 

dendq 

choice 1 

cend 1/1 


display clear 
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************************************************************ 

* INITIAL ESTIMATES FOR THIS PROJECT: * 

* 

* System Size 42000. DSI * 

* Cost of Programming Phase #T0TMD1 Person Days * 

* Duration of Programming Phase #TDEV Days * 

* * 

* The initial core team of software developers who have* 

* just completed the reguirements and design * 

* specifications is #WFS1 people. * 

* * 

* Your task is to take over as manager of the * 

* programming phase. At this point, you need to make 2* 

* decisions: * 

* * 

* 1. The total staff level for the programming phase. * 

* * 

* 2. The percent of this staff to allocate to Quality * 

* Assurance. * 


-> FIRST DECISION: The total staff level 

Enter your total reguested staff level and press <ENTER>. 
dendg 

dq WFS1=0.5< 
display clear 


-> SECOND DECISION: 

NEW tool's estimate for the percent of the total staff to 
allocate to QA is #FRMPQA percent. Remember, NEW_TOOL has 
not yet been calibrated to your environment. Thus, this 
estimate is merely illustrative. It may or may not be 
appropriate for your unique project. 

1) Enter a different desired percentage (a number from 0 - 
100) and press <ENTER>. 

OR 

2) Press <ENTER> to allocate #FRMPQA percent of your staff 
to QA. 

dendg 

dq FRMPQA=0<100 
display clear 

Your total requested staffing level = #WFS1 
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people. 

The percent to be devoted to QA activities = #FRMPQA 
percent. 

(This means that you are devoting #WFS1 * #FRMPQA / 100 = 

#WFS1*FRMPQA/100 people to QA) 


******************************************************** 

* !! IMPORTANT !! * 

* * 

* This is your final opportunity to check and * 

* change the values for this period. * 

* * 

* Press 1 then <ENTER> to change these values. * 

* * 

* If all values are correct, record them on * 

* the documentation sheet provided then * 

* * 

* Press 2 then <ENTER> to continue. * 

* * 
******************************************************** 
dend 

choice 2 

display 

Your total requested staffing level = 
dendq 

dq WFS1=0.5< 
display 

The percent allocated to QA = 
dendq 

dq FRMPQA=0<100 

cend 

cend 

else 

choice 1 
cend 1/1 
display clear 

************************************************** 

* Make Your Desired Changes To The Variables * 

* and press <ENTER> * 

* OR * 

* Press <ENTER> to keep the displayed value * 
************************************************** 


Your updated estimate for project cost (person days) 
dendq 

dq TOTMD1=0< 
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display 

Your updated estimate for project duration (days) = 
dendq 

dq PROJDR=0< 
display 

Your total requested staffing level = 
dendq 

dq WFS1=0.5< 
display 

The percent to allocate to QA (a number from 0 - 100) = 
dendq 

dq FRMPQA=0<100 


display clear 

Your updated estimate for project cost = #TOTMDl 

person days 

Your updated estimate for project duration = #PROJDR 

days 

Your total requested staffing level = #WFS1 

people 

The percent to be devoted to QA activities = #FRMPQA 

percent 

(This means that you are devoting #WFS1 * #FRMPQA / 100 - 

#WFS1*FRMPQA/100 people to QA) 


******************************************************** 

* 1! IMPORTANT !! * 

* * 

* This is your final opportunity to check and * 

* change the values for this period. * 

* * 

* Press 1 then <ENTER> to change these values. * 

* * 

* If all values are correct, record them on * 

* the documentation sheet provided then * 

j. * 

* 

* Press 2 then <ENTER> to continue. * 

* * 
******************************************************** 
dend 

choice 2 


display 

The updated estimate for project cost (person days) = 
dendq 
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dq TOTMD1=0< 


display 

The updated estimate for project duration (days) = 
dendq 

dq PROJDR=0< 
display 

Your total requested staffing level = 
dendq 

dq WFS1=0.5< 
display 

The percent allocated to QA = 
dendq 

dq FRMPQA=0<100 

cend 

cend 

end 

display 

************************************************************ 

* Press <ENTER> to simulate this interval and return to * 

* the menu. * 

* * 
************************************************************ 
dendq 

choice 1 
display clear 

******************************************** 


* There will be a short pause while 

* the model simulates the next period. 


******************************************** 

dendq 

report 

time=maxtime, 
cend 1/1 

spec md_length=#length+40 
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APPENDIX K: UNCERTAINTY GROUP INSTRUCTION SET (Al) 

Your Name: _ Al 

SMC No.: _ 

1. Introduction 

The exercise you are about to undertake is similar in many ways to flight simulators 
that pilots use to mimic flying an aircraft from takeoff at point A to landing at point B. 
Instead of flying an aircraft, though, the simulator mimics the programming phase of a real 
software project. In this simulation, you will be more than an observer. In fact, you will 
play the role of manager of the programming phase of the project. Specifically, your role 
will be to track the progress of the project by reviewing status reports and graphs available 
every two-month interval (40 working days) during the programming phase. As the 
manager, you must then make two staffing decisions: 

First, the total number of staff you need. (You can hire additional staff, 
or decrease the staffing level as you deem necessary to complete your 
programming task successfully.) 

Second, you need to decide on what percent of your total staff to allocate 
to the Quality Assurance activity to be conduct^ throughout the programming 
phase (e.g. to do inspections). 

2. Project 

The project that you will manage happens to have been a real project conducted in a 
real organization. For the project, you will be given a project profile containing the 
following initial information: 

Estimated Size of the System: in Delivered Source Instructions (DSI) 

Estimated Cost of Programming Phase: in Number of Person Days 

Estimated Duration of Programming Phase: in Number of Work Days 

Size of initial Core Team: in People 

The Core Team is a skeleton staff of software professionals who are there to ensure 
continuity between the requirements/design phase (which you may assume has just been 
completed), and the programming phase you are to manage. 

The cost and schedule estimates are derived from a new off-the-shelf estimation tool, 
call it "NEW_TOOL", that has been recently acquired. 

Historically, the defect density (i.e. number of defects detected during programming 
divided by the number of KDSI developed) has ranged from 5-20 Defects/KDSI. 
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3. Your task 


Your task at every 40-day interval is to review the project’s status, and to make any 
necessary adjustments to the staffing level and its allocation. In order to do so, you may feel 
that is necessary to first adjust the project’s cost and duration targets. The staffing decision 
should be done as follows: 

1. Decide on the total staffing level, and 

2. Decide on what percentage of the staff should be allocated to the quality assurance 
function (i.e. a number between 0 and 100). 

4. Your Goal for the Task: 


Minimiz e overruns in both cost and schedule. 


Your grade for the simulation will be based on an equal weighing of these two factors. 

5. Some Important Points to Consider in Managing Your Task 

1. As the manager of the programming phase, you specify the desired staffing level. 
You may find that your actual staffing level (as it will appear in the reports) is 
different from what you requested. This would be due to the delay in hiring 
people. For modest additions to your staffing, the average hiring delay will be 
around 40 days. However if you request a large number of additional staff, the 
average hiring delay will be much longer. 

2. Once new people are hired, they must be trained and assimilated. The 
assimilation/tiaining period is typically 80 days. During this assimilation/training 
period you can expect the new employee to be only half as productive as an 
experienced employee. 

3. The staff size that you select, and which appears in reports, may show fractions 
(e.g. 4,5 people) since people are allowed to work on more than one project. 

4. Adding more people increases communication and coordination overhead as 
happens in reality. 
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5. You will need to take into account the possibility of losing people due to turnover. 
You will receive a staff loss notice once a turnover occurs. 

6. Rules of the Game 

1. You must work alone. At no time are you to discuss the progress of the project 
with anyone. 

2. If you have a question, ask the lab attendant. 

3 You are not allowed to bring any notes or other "gouge" to use during the 
simulation. Feel free to write on the documentation sheets provided. 

4. A calculator is allowed and recommended. 

7. Instructions for Starting the System 

Follow the instructions Carefully . If any problems arise, immediately seek out the lab 
attendant. 

1. Insert the disk into the B: drive. Do not remove the disk from the drive! 

2. From the C:\ prompt, type B: Do NOT start the network! 

3. Start the simulation by typing START at the B:\ prompt. 

4. Follow the instructions as they appear on the screen. 

5. The simulation is complete when the % Programming Reported Complete in 
the PROJECT STATUS REPORT is 100%. When this occurs Call the lab 
attendant. 
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Your Name: 
SMC No.: 


YOUR GOAL IS: 


Minimiz e overruns in both cost and schedule. 


INITIAL ESTIMATES: 


Project Size 42,000 DSI 

Project Cost 1887 Person Days 

Project Duration (start-end) 237 Days 


TIME ELAPSED 
(DAYS) 

ESTIMATED 

COST 

(PERS-DAYS) 

ESTIMATED 

DURATION 

(DAYS) 

STAFFING 

LEVEL 

(PERSONS) 

QUALITY 

ASSURANCE 

(PERCENT) 

Initial Decision 

1887 

237 



Time Elapsed - 40 Days 





Time Elapsed - 80 Days 





Time Elapsed - 120 Days 





Time Elapsed - 160 Days 





Time Elapsed - 200 Days 





Time Elapsed - 240 Days 





Time Elapsed - 280 Days 





Time Elapsed - 320 Days 





Time Elapsed - 360 Days 





Time Elapsed - 400 Days 





Time Elapsed - 440 Days 





Time Elapsed - 480 Days 





Time Elapsed - 520 Days 




ikTnn all*4'*1* 


*♦♦♦ whLN VOU AriTdone, call the lab ATTENDAN 1 
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APPENDIX L; RISK GROUP INSTRUCTION SET (A2) 


Your Name: 
SMC No.: 


1. Introduction 

The exercise you are about to undertake is similar in many ways to flight simulators 
that pilots use to mimic flying an aircraft from takeoff at point A to landing at point B. 
Instead of flying an aircraft, though, the simulator mimics the programming phase of a real 
software project. In this simulation, you will be more than an observer. In fact, you will 
play the role of manager of the programming phase of the project. Specifically, your role 
will be to track the progress of the project by reviewing status reports and graphs available 
every two-month interval (40 working days) during the programming phase. As the 
manager, you must then make two staffing decisions: 

First, the total number of staff you need. (You can hire additional staff, 
or decrease the staffing level as you deem necessary to complete your 
programming task successfully.) 

Second, you need to decide on what percent of your total staff to allocate 
to the Quality Assurance activity to be conducted throughout the programming 
phase (e.g. to do inspections). 

2. Project 

The project that you will manage happens to have been a real project conducted in a 
real organization. For Ae project, you will be given a project profile containing the 
following initial information: 

Estimated Size of the System: in Delivered Source Instructions (DSI) 

Estimated Cost of Programming Phase: in Number of Person Days 

Estimated Duration of Programming Phase: in Number of Work Days 

Size of initial Core Team: in People 

The Core Team is a skeleton staff of software professionals who are there to ensure 
continuity between the requirements/design phase (which you may assume has just been 
completed), and the programming phase you are to manage. 

The cost and schedule estimates are derived from a new off-the-shelf estimation tool, 
call it "NEW_TOOL", that has been recently acquired. 

Historically, the defect density (i.e. number of defects detected during programming 
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divided by the number of KDSI developed) has ranged from 5 - 20 Defects/KDSI. 

3. Your task 

Your task at every 40-day interval is to review the project’s status, and to make any 
necessary adjustments to the staffing level and its allocation. In order to do so, you may feel 
that is necessary to first adjust the project’s cost and duration targets. The staffing decision 
should be done as follows: 

1. Decide on the total staffing level, and 

2. Decide on what percentage of the staff should be allocated to the quality assurance 
function (i.e. a number between 0 and 100). 

4. Your Goal for the Task: 


Minimiz e Overruns in both cost and schedule. 


Your grade for the simulation will be based on an equal weighing of these two factors. 

5. Some Important Points to Consider in Managing Your Task 

1. As the manager of the programming phase, you specify the desired staffing level. 
You may find that your actual staffing level (as it will appear in the reports) is 
different from what you requested. This would be due to the delay in hiring 
people. For modest additions to your staffing, the average hiring delay will be 
around 40 days. However if you request a large number of additional staff, the 
average hiring delay will be much longer. 

2. Once new people are hired, they must be trained and assimilated. The 
assimilation/training period is typically 80 days. During this assimilation/training 
period you can expect the new employee to be only half as productive as an 
experienced employee. 

3. The staff size that you select, and which appears in reports, may show fractions 
(e.g. 4.5 people) since people are allowed to work on more than one project. 

4. Adding more people increases communication and coordination overhead as 
happens in reality. 
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5. A project risk in this organization is that of losing people due to turnover. 
Historically, the turnover rate averages to 1.5 people lost every reporting period 
(i.e., every 40 days). 

The following are the probabilities of possible staff losses every 40 day period: 

25 % probability of no loss in staff. 

25 % probability of 1 person lost. 

25 % probability of 2 people lost. 

25 % probability of 3 people lost. 

You will receive a staff loss notice once a turnover occurs. 

6. Rules of the Game 

1. You must work alone. At no time are you to discuss the progress of the project 
with anyone. 

2. If you have a question, ask the lab attendant. 

3 You are not allowed to bring any notes or other "gouge" to use during the 
simulation. Feel free to write on the documentation sheets provided. 

4. A calculator is allowed and recommended. 

7. Instructions for Starting the System 

Follow the instructions Carefiillv . If any problems arise, immediately seek out the lab 
attendant. 

1. Insert the disk into the B: drive. Do not remove the disk from the drive! 

2. From the C:\ prompt, type B: Do NOT start the network! 

3. Start the simulation by typing START at the B:\ prompt. 

4. Follow the instructions as they appear on the screen. 

5. The simulation is complete when the % Programming Reported Complete in 
the PROJECT STATUS REPORT is 100%. When this occurs Call the lab 
attendant. 
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Your Name: 
SMC No.: 


YOUR GOAL IS: 


Minimiz e overruns in both cost and schedule. 


INITIAL ESTIMATES: 

Project Size 
Project Cost 

Project Duration (start-end) 


42,000 DSI 
1887 Person Days 
237 Days 
































APPENDIX M; CERTAINTY GROUP INSTRUCTION SET (Bl) 


Your Name: __ 

SMC No.: _ 

1. Introduction 

The exercise you are about to undertake is similar in many ways to flight simulators 
that pilots use to mimic flying an aircraft from takeoff at point A to landing at point B. 
Instead of flying an aircraft, though, the simulator mimics the programming phase of a real 
software project. In this simulation, you will be more than an observer. In fact, you will 
play the role of manager of the programming phase of the project. Specifically, your role 
wiU be to track the progress of the project by reviewing status reports and graphs available 
every two-month interval (40 working days) during the programming phase. As the 
manager, you must then make two staffing decisions. 

First, the total number of staff you need. (You can hire additional staff, 
or decrease the staffing level as you deem necessary to complete your 
programming task successfully.) 

Second, you need to decide on what percent of your total staff to allocate 
to the Quality Assurance activity to be conducted throughout the programming 
phase (e.g. to do inspections). 

2. Project 

The project that you will manage happens to have been a real project conducted in a 
real organization. For the project, you will be given a project profile containing the 
following initial information: 

Estimated Size of the System: in Delivered Source Instructions (DSI) 

Estimated Cost of Programming Phase: in Number of Person Days 

Estimated Duration of Programming Phase: in Number of Work Days 

Size of initial Core Team: in People 

The Core Team is a skeleton staff of software professionals who are there to ensure 
continuity between the requirements/design phase (which you may assume has just been 
completed), and the programming phase you are to manage. 

The cost and schedule estimates are derived from a new off-the-shelf estimation tool, 
call it "NEW_TOOL", that has been recently acquired. 

Historically, the defect density (i.e. number of defects detected during programming 
divided by the number of KDSI developed) has ranged from 5-20 Defects/KDSI. 
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3. Your task 


Your task at every 40-day interval is to review the project’s status, and to make any 
necessary adjustments to the staffing level and its allocation. In order to do so, you m^ feel 
that is necessary to first adjust the project’s cost and duration targets. The staffing decision 
should be done as follows: 

1. Decide on the total staffing level, and 

2. Decide on what percentage of the staff should be allocated to the quality assurance 
function (i.e. a number between 0 and 100). 

4. Your Goal for the Task: 


Minimize overruns in both cost and schedule. 


Your grade for the si mula tion will be based on an equal weighing of these two factors. 

5. Some Important Points to Consider in Managing Your Task 

1. As the manager of the programming phase, you specify the desired staffing level. 
You may find that your actual staffing level (as it will appear in the reports) is 
different from what you requested. This would be due to the delay in hiring 
people. For modest additions to your staffing, the average hiring delay will be 
around 40 days. However if you request a large number of additional staff, the 
average hiring delay will be much longer. 

2. Once new people are hired, they must be trained and assimilated. The 
assimilation/training period is typically 80 days. During this assimilation/training 
period you can expect the new employee to be only half as productive as an 
experienced employee. 

3. The staff size that you select, and which appears in reports, may show fractions 
(e.g. 4.5 people) since people are allowed to work on more than one project. 

4. Adding more people increases communication and coordination overhead as 
happens in reality. 
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5. A project risk in this organization is that of losing people due to turnover. 
Historically, the turnover rate averages to 1.5 people lost every reporting period 
(i.e., every 40 days). 

To minimize the negative impacts of staff turnover on a project, the 
organization has instituted a policy of requiring a 40 day notice of leaving. As the 
project manager, this guarantees that you will be aware of any staff losses in a 40 
day period at the beginning of the period. 

You will receive a staff loss notice once an employee plans to leave. 

6. Rules of the Game 

1. You must work alone. At no time are you to discuss the progress of the project 
with anyone. 

2. If you have a question, ask the lab attendant. 

3 You are not allowed to bring any notes or other "gouge" to use during the 
simulation. Feel free to write on the documentation sheets provided. 

4. A calculator is allowed and recommended. 

7. Instructions for Starting the System 

Follow the instructions Carefully . If any problems arise, immediately seek out the lab 
attendant. 

1. Insert the disk into the B: drive. Do not remove the disk from the drive! 

2. From the C:\ prompt, type B: Do NOT start the network! 

3. Start the simulation by typing START at the B:\ prompt. 

4. Follow the instructions as they appear on the screen. 

5. The simulation is complete when the % Programming Reported Complete in 
the PROJECT STATUS REPORT is 100%. When this occurs Call the lab 
attendant. 


73 



Your Name: 
SMC No.: 


YOUR GOAL IS: 


Minimiz e ovemins in both cost and schedule. 


INITIAL ESTIMATES: 

Project Size 
Project Cost 

Project Duration (start-end) 


42,000 DSI 
1887 Person Days 
237 Days 



TIME ELAPSED 
(DAYS) 


Initial Decision 


Time Elapsed - 40 Days 


Time Elapsed - 80 Days 


Time Elapsed - 120 Days 


Time Elapsed - 160 Days 


Time Elapsed - 200 Days 


Time Elapsed - 240 Days 


ESTIMATED 

COST 

(PERS-DAYS) 


ESTIMATED 

DURATION 

(DAYS) 


STAFFING 

LEVEL 

(PERSONS) 


QUALITY 

ASSURANCE 

(PERCENT) 



Time Elapsed - 280 Days 


Time Elapsed - 320 Days 


Time Elapsed - 360 Days 


Time Elapsed - 400 Days 


Time Elapsed - 440 Days 


Time Elapsed - 480 Days 


Time Elapsed - 520 Days 


*otwhEN y 


RE DONE. CALL THE LAB ATTENDANT **** 


































APPENDK N: PRACTICE EXPERIMENT INSTRUCTION SET 


Your Name: __ 

SMC No.: __ 

1. Introduction 

The exercise you are about to undertake is similar in many ways to flight simulators 
that pilots use to mimic flying an aircraft from takeoff at point A to landing at point B. 
Instead of flying an aircraft, though, the simulator mimics the programming phase of a real 
software project. In this simulation, you will be more than an observer. In fact, you will 
play the role of manager of the programming phase of the project. Specifically, your role 
will be to track the progress of the project by reviewing status reports and graphs available 
every two-month interval (40 working days) during the programming phase. As the 
manager, you must then make two staffing decisions: 

First, the total number of staff you need. (You can hire additional staff, 
or decrease the staffing level as you deem necessary to complete your 
programming task successfully.) 

Second, you need to decide on what percent of your total staff to allocate 
to the Quality Assurance activity to be conducted throughout the programming 
phase (e.g. to do inspections). 

2. Project 

The project that you will manage happens to have been a real project conducted in a 
real organization. For the project, you will be given a project profile containing the 
following initial information: 

Estimated Size of the System: in Delivered Source Instructions (DSI) 

Estimated Cost of Programming Phase: in Number of Person Days 

Estimated Duration of Programming Phase: in Number of Work Days 

Size of initial Core Team: in People 

The Core Team is a skeleton staff of software professionals who are there to ensure 
continuity between the requirements/design phase (which you may assume has just been 
completed), and the programming phase you are to manage. 

The cost and schedule estimates are derived from a new off-the-shelf estimation tool, 
call it "NEW_TOOL", that has been recently acquired. 

Historically, the defect density (i.e. number of defects detected during programming 
divided by the number of KDSI developed) has ranged from 5-20 Defects/KDSI. 
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3. Your task 


Your task at every 40-day interval is to review the project’s status, and to make any 
necessary adjustments to the staffing level and its allocation. In order to do so, you may feel 
that is necessary to first adjust the project’s cost and duration targets. The staffing decision 
should be done as follows: 

1. Decide on the total staffing level, and 

2. Decide on what percentage of the staff should be allocated to the quality assurance 
function (i.e. a number between 0 and 100). 

4. Your Goal for the Task; 


Familiarize yourself with the simulation. 


5. Some Important Points to Consider in Managing Your Task 

1. As the manager of the programming phase, you specify the desired staffing level. 
You may find that your actual staffing level (as it will appear in the reports) is 
different from what you requested. This would be due to the delay in hiring 
people. For modest additions to your staffing, the average hiring delay will be 
around 40 days. However if you request a large number of additional staff, the 
average hiring delay will be much longer. 

2. Once new people are hired, they must be trained and assimilated. The 
assimilation/training period is typically 80 days. During this assimilation/training 
period you can expect the new employee to be only half as productive as an 
experienced employee. 

3. The staff size that you select, and which appears in reports, may show fractions 
(e.g. 4.5 people) since people are allowed to work on more than one project. 

4. Adding more people increases communication and coordination overhead as 
happens in reality. 
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6. Rules of the Game 


1. You must work alone. At no time are you to discuss the progress of the project 
with anyone. 

2. If you have a question, ask the lab attendant. 

3 You are not allowed to bring any notes or other "gouge" to use during the 
simulation. Feel free to write on the documentation sheets provided. 

4. A calculator is allowed and recommended. 

7. Instructions for Starting the System 

Follow the instructions Carefully . If any problems arise, immediately seek out the lab 
attendant. 

1. Insert the disk into the B: drive. Do not remove the disk from the drive! 

2. From the C:\ prompt, type B: Do NOT start the network! 

3. Start the simulation by typing PRACTICE at the B:\ prompt. 

4. Follow the instructions as they appear on the screen. 

5. The simulation is complete when the % Programming Reported Complete in 
the PROJECT STATUS REPORT is 100%. When this occurs Call the lab 
attendant. 
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Your Name: 
SMC No.: 


YOUR GOAL IS: 


Familiarize yourself with the sunulation. 


INITIAL ESTIMATES: 

Project Size 
Project Cost 

Project Duration (start-end) 


ESTIMATED 

DURATION 

(DAYS) 


20,000 DSI 
1400 Person Days 
350 Days 


STAFFING QUALITY 

LEVEL ASSURANCE 

(PERSONS) (PERCENT) 



520 Days 


H 




RET)ONE. CALLTBELAB^TTENDANT**** 
































APPENDIX O: GRAPHS.DRS FILES 


STATPLOT.DRS 

plotxy <TM"TIME (DAYS) ",0,600>, <FTEQWF"TOTAL STAFF (PERSONS) 
",0,40>, 

<PJBSZT/1000"EST SYSTEM SIZE (KDSI) ",0,80>, 

<JBSZMD"EST PROGRAMMING COST (PERSON DAYS) ",0,6000> 

STAFPLOT.DRS 

plotxy <TM"TIME (DAYS) ",0,600>, <FTEQWF"TOTAL STAFF (PERSONS) 
",0,40>, 

’<CRQAWF"QA STAFF (PERSONS) ",0,40>, <CRDVWF"PROG STAFF 
(PERSONS) ",0,40> 

DEFPLOT.DRS 

plotxy <TM"TIME (DAYS) ",0,600>,<PRQAMD"QA PERSON DAYS PER 
PERIOD ",0,240>, 

<PRERD"DEFECTS DETECTED PER PERIOD ",0,240> 
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APPENDIX P: RANDOMIZATION WORKSHEET 


Kelly, John 

104 

King, A. 

150 

Lamb, V. 

015 

Langhorne, W. 

020 

Larochelle, L. 

816 

Lewis, J. 

916 

Mancano, V. 

691 

jMxchal, 7 • 

141 

Nault, M. 

625 

Oneill, T. 

223 

Onorati, A. 

465 

Pemberton, L. 

255 

Prell, M. 

853 

Robillard, S. 

309 

Sears, G. 

891 

Staten, R* 

279 

Tate, W. 

939 

Trepanier, D. 

241 

Weiss, K. 

483 

Wilcox, R. 

225 

Chou, M. 

972 

Kelly, James 

763 

Barnum, T* 

648 

Berry, E. 

151 

Bitzer, S. 

248 

Callaghan, V. 

493 

Cragmiles, R. 

421 

Downs, M. 

930 

Emde, C. 

062 

Emswiler, T. 

616 

Encinas, T* 

078 

Franklin, B. 

163 

Gregorie, J. 

394 

Hodges, J. 

535 

Howard, L. 

713 

Johnson, S. 

375 

McGibbon, H. 

399 

McQuay, D. 

818 

Monroe, W. 

166 

Swain, W. 

917 

Tharpe, G. 

604 
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Both Experiments No goals 

Experi ments- 


A1 Uncertainty 
A2 Risk 
B1 Certainty 
Order 

1 C/S 

2 S/C 

+ No goals experiment 
* Attend but not in 


Not in McCaffrey* 


41 Students 










APPENDIX Q: PERFORMANCE VARIABLES 


FNCOST 

Final 

FNSKED 

Final 

FNERR 

Final 

FNERG 

Final 

FNERD 

Final 

FNERES 

Final 

FNPRDT 

Final 

FNQAMD 

Final 

FNTRMD 

Final 

FNRWMD 

Final 


Cost (Person Days) 

Cumulative Time (Days) 

Errors Remaining Undetected 
Cumulative Errors Generated 
Cumulative Errors Detected 
Cumulative Errors Escaping Detection 
Percentage of Errors Detected 
Cumulative Quality Assurance Person Days 
Cumulative Training Person Days 
Cumulative Rework Person Days 
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Your Ncime 
SMC No,: 


APPENDIX R: PROJECT QUESTIONNAIRE 


Group All 

1, In making your decisions, how much weight out of 100 points 
did you accord to the following goals? (The numbers should total 

100 points.) 

Cost _ 


Schedule _ 

100 

2. Describe (in words, numbers, equation, etc.) what decision rule 
you followed in deciding on the overall staffing level in this 
project: 


3. Please try to elaborate on the thinking process you went 
through in making your decisions in this project (use back of 
if necessary): 


4, Please elaborate on how you handled the problem of staff 
turnover. 


5. How clear were the instructions regarding the task? 

123456789 
Not at all Very 

Clear Clear 
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To what extent was the graphical information provided on the 
progress of the project helpful in improving your own decisions 

1 23456789 

Not at all very 

Helpful Helpful 


To what extent were the reports on the progress of the project 
helpful in improving your own decisions? 

1 23456789 

Not at all Very 

Helpful Helpful 

In the project that you just completed, did you 

(a) Use the PROJECT STATUS report (Y/N)? _ 

(b) If you did, please describe how you used the information. 


In the project that you just completed, did you 

(a) Use the STAFFING LEVEL report (Y/N)? _ 

(b) If you did, please describe how you used the information. 


In the project that you just completed, did you 

(a) Use the DEFECT report (Y/N)? _ 

(b) If you did, please describe how you used the information. 



In the project that you just completed, did you 

(a) Use the CUMULATIVE report (Y/N)? _ 

(b) If you did, please describe how you used the information. 


In the project you just completed, did you 

(a) Use the PROJECT STATUS graph (Y/N)? _ 

(b) If you did, please describe how you used the information. 


In the project that you just completed, did you 

(a) Use the STAFFING LEVEL graph (Y/N)? _ 

(b) If you did, please describe how you used the information. 


In the project that you just completed, did you 

(a) Use the DEFECT graph (Y/N)? _ 

(b) If you did, please describe how you used the information. 


Have you in the past participated in project management (Y/N)? 

If YES, to what extent was the task in this simulation similar to 
your previous experience? 

1 23456789 

Not at all Very 

Similar Similar 



16. 


How interesting was the task you just performed? 


1 2 
Not at all 
Interesting 


9 

Very 

Interesting 


How serious were you in performing the task? 


1 2 
Not at all 
Serious 


9 

Very 

Serious 


How clear were the instructions regarding the task, generally? 


1 2 
Not at all 
Clear 


Clear 


How easy was the simulation to use? 


1 2 
Not at all 
Easy 


9 

Very 

Easy 


Please give us some information about yourself^absolute 
confidence. At no time will your name appear in the results. The 
data will only be used in an aggregate statistical sense). 

(a) Curriculum enrolled in: _____ 

(b) Age -- 

(c) Sex - 

(d) Full time work experience (in years) __ 

(e) How long ago (in years) did --- 

you complete your 

undergraduate education? 

(f) How familiar are you with computers, generally? 

123456789 

Not at all . 

Familiar Famrlxar 

(g) How many hours (per week) do you use computers? 
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21. 


Your general comments regarding the simulation: 


*** END OF SIMULATION *** 
Thank you for your participation. 
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APPENDIX S: FORMAT OF DEMOGRAPHIC DATA 


QIS 

Question 1 Schedule Percent 

QlQ 

Question 1 Quality Percent 

QIC 

Question 1 Cost Percent 

Q5 

Question 5 Response (1-9) 

Q6 

Question 6 Response (1-9) 

Q7 

Question 7 Response (1-9) 

Q8 

Question 8 Response (0/1 0-No 1-Yes) 

09 

Question 9 Response (0/1 0-No 1-Yes) 

QIO 

Question 10 Response (0/1 0-No 1-Yes) 

Qll 

Question 11 Response (0/1 0-No 1-Yes) 

Q12 

Question 12 Response (0/1 0-No 1-Yes) 

Q13 

Question 13 Response (0/1 0-No 1-Yes) 

Q14 

Question 14 Response (0-9 0-No 1-9 Yes and the value) 

Q15 

Question 15 Response (1-9) 

Q16 

Question 16 Response (1-9) 

Q17 

Question 17 Response (1-9) 

Q18 

Question 18 Response (1-9) 

Q19 

Question 19 Response (1-9) 

CURR 

Curriculum 

AGE 

Age (years) 

SEX 

M=Male, F=Female 

WKEXP 

Work Experience (years) 

EDAGO 

Years since undergraduate education was completed 

FAM 

Computer familiarity 

CHRSWK 

Number of computer hours per week 
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1 

1995 


APPENDIX T: PERFORMANCE/DEMOGRAPHIC DATA 

Risk experiment: Comparison of performance 

• 12:21 Tuesday, July 25, 

- PROJECT=A RISKTyPE=R 


Variable 

N 

Mean 

Std Dev 

Minimum 

Maximum 

FNCOST 

14 

2941.76 

523.7349118 

2256.31 

4146.24 

FNSKED 

14 

310.2142857 

43.5447225 

258.0000000 

390.5000000 

FNERR 

14 

14654.44 

9912.12 

2008.65 

32462.84 

FNERG 

14 

1819.48 

119.1415691 

1676.29 

2032.23 

FNERD 

14 

592.0057143 

369.7023526 

216.1100000 

1432.60 

FNERES 

14 

1227.47 

342.4663414 

409.1300000 

1608.85 

FNPRDT 

14 

32.2107143 

19.3308098 

12.0000000 

77.7900000 

FNQAMD 

14 

347.5107143 

267.8133500 

119.7700000 

1036.56 

FNTRMD 

14 

233.6628571 

39.3861243 

163.7800000 

316.1500000 

FNRWMD 

14 

426.0671429 

261.2214201 

168.4100000 

1006.00 

Q1 

14 

53.2142857 

10.6711586 

35.0000000 

70.0000000 

Q2 

14 

0 

0 

0 

0 

Q3 

14 

46.7857143 

10.6711586 

30.0000000 

65.0000000 

Q4 

14 

7.8571429 

1.7913099 

3.0000000 

9.0000000 

Q5 

14 

4.7857143 

3.2623392 

1.0000000 

9.0000000 

Q6 

14 

7.6428571 

2.0232169 

3.0000000 

9.0000000 

Q7 

14 

0.9285714 

0.2672612 

0 

1.0000000 

Q8 

14 

0.9285714 

0.2672612 

0 

1.0000000 

Q9 

14 

0.7142857 

0.4688072 

0 

1.0000000 

QIO 

14 

0.6428571 

0.4972452 

0 

1.0000000 

Qll 

14 

0.5000000 

0.5188745 

0 

1.0000000 

Q12 

14 

0.3571429 

0.4972452 

0 

1.0000000 

Q13 

14 

0.2857143 

0.4688072 

0 

1.0000000 

Q14 

14 

5.2142857 

3.5772480 

0 

9.0000000 

Q15 

14 

6.7142857 

1.8156826 

4.0000000 

9.0000000 

Q16 

14 

7.8571429 

1.1673206 

5.0000000 

9.0000000 

Q17 

14 

8.0714286 

1.3847680 

4.0000000 

9.0000000 

Q18 

14 

8.2857143 

1.4373358 

4.0000000 

9.0000000 

Q20 

14 

34.5000000 

5.3601091 

28.0000000 

44.0000000 

Q22 

14 

12.6071429 

6.1022649 

6.0000000 

26.0000000 

Q23 

14 

10.8214286 

5.4688177 

6.0000000 

23.0000000 

Q24 

14 

7.3571429 

1.7805420 

3.0000000 

9.0000000 

Q25 

14 

15.7857143 

12.0203582 

2.0000000 

50.0000000 


Risk experiment: Comparison of performance 


* 12:21 Tuesday, July 25, 

1995 


PROJECT=A RISKTypE=U 


Variable N 


FNCOST 15 
FNSKED 15 


Mean 


3333.66 

339.1555556 


Std Dev 


733.0443938 

54.8975766 


Minimum 


2468.45 

247.5416667 


Maximum 


4895.83 

451.7500000 
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3 


FNERR 

15 

FNERG 

15 

FNERD 

15 

FNERES 

15 

FNPRDT 

15 

FNQAMD 

15 

FNTRMD 

15 

FNRWMD 

15 

Q1 

15 

Q2 

15 

Q3 

15 

Q4 

15 

Q5 

15 

Q6 

15 

Q7 

15 

Q8 

15 

Q9 

15 

QIO 

15 

Qll 

15 

Q12 

15 

Q13 

15 

Q14 

15 

Q15 

15 

Q16 

15 

Q17 

15 

Q18 

15 

Q20 

15 

Q22 

15 

Q23 

15 

Q24 

15 

Q25 

15 


13414.73 

1730.40 

542.8013333 

1187.60 

31.8653333 

352.9280000 

231.2413333 

412.7433333 

51.6666667 

0 

48.3333333 

8.4000000 
5.1333333 
8.0000000 
1.0000000 
0.7333333 
0.5333333 
0.4000000 
0.5333333 
0.2666667 
0.3333333 
1.6000000 
7.8666667 
8.2000000 
8.5333333 
7.7333333 

34.9333333 

14.3333333 
13.2666667 

7.4000000 
28.1333333 


10470.29 

106.0497911 

416.9957476 

457.0779389 

25.6257889 

323.1240968 

37.6845861 

326.2204636 

9.9402980 

0 

9.9402980 

0.9856108 

3.2041640 

0.9258201 

0 

0.4577377 

0.5163978 

0.5070926 

0.5163978 

0.4577377 

0.4879500 

2.6672618 

1.3020131 

0.5606119 

0.6399405 

1.1629192 

6.0411289 

6.4660284 

6.1582310 

1.5491933 

19.9530401 


1710.86 

1591.83 

0 

429.0900000 

0 

0 

181.1500000 

0 

30.0000000 

0 

25.0000000 

6.0000000 

1.0000000 

7.0000000 

1.0000000 

0 

0 

0 

0 

0 

0 

0 

6.0000000 

7.0000000 

7.0000000 

5.0000000 

26.0000000 

5.0000000 

5.0000000 

3.0000000 

6.0000000 


30882.80 

1909.39 

1209.17 

1662.76 

73.8100000 

972.8700000 

302.9500000 

996.0900000 

75.0000000 

0 

70.0000000 

9.0000000 

9.0000000 

9.0000000 

1.0000000 

1.0000000 

1.0000000 

1.0000000 

1.0000000 

1,0000000 

1.0000000 

7.0000000 

9.0000000 

9.0000000 

9.0000000 

9.0000000 

47.0000000 

27.0000000 

25.0000000 

9.0000000 

90.0000000 


Risk experiment: Comparison of performance 

* 12:21 Tuesday^ July 25, 


1995 


PROJECT=B RISKTYPE=C 


Variable 

N 

FNCOST 

12 

FNSKED 

12 

FNERR 

12 

FNERG 

12 

FNERD 

12 

FNERES 

12 

FNPRDT 

12 

FNQAMD 

12 

FNTRMD 

12 

FNRWMD 

12 

Ql 

12 

Q2 

12 

Q3 

12 

Q4 

12 

Q5 

12 

Q6 

12 

Q7 

12 


Mean 


2667.01 

274.6428571 

11559.47 

1711.85 

576.1850000 

1135.66 

33.9508333 

340.0333333 

262.0550000 

465.0475000 

56.6666667 

0 

43.3333333 

8.0000000 

4.9166667 

8.4166667 

1.0000000 


Std Dev 


425.9057526 

47.4928566 

8144.78 

119.6097295 

218.4170454 

267.6175064 

13.4710818 

140.0635348 

44.6549005 

189.0080956 

11.5470054 

0 

11.5470054 

1.7056057 

2.4664414 

0.7929615 

0 


Minimum 


1705.57 

206.5714286 

2170.06 

1635.10 

0 

709.3500000 

0 

0 

184.1100000 

0 

40.0000000 

0 

20.0000000 

3.0000000 

1.0000000 

7.0000000 

1.0000000 


Maximum 


3299.61 

383.5714286 

31597.91 

1997.45 

925.7500000 

1737.02 

56.6200000 

594.1300000 

327.1300000 
788.1800000 

80.0000000 

0 

60.0000000 

9.0000000 

9.0000000 

9.0000000 

1.0000000 
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Q8 

12 

0.9166667 

0.2886751 

0 

1.0000000 

Q9 

12 

0.8333333 

0.3892495 

0 

1.0000000 

QIO 

12 

0.6666667 

0.4923660 

0 

1.0000000 

Qll 

12 

0.5000000 

0.5222330 

0 

1.0000000 

Q12 

12 

0.2500000 

0.4522670 

0 

1.0000000 

Q13 

12 

0.3333333 

0.4923660 

0 

1.0000000 

Q14 

12 

0.7500000 

2.5980762 

0 

9.0000000 

Q15 

12 

8.0833333 

1.3113722 

5.0000000 

9.0000000 

Q16 

12 

8.4166667 

0.7929615 

7.0000000 

9.0000000 

Q17 

12 

8.3333333 

0.9847319 

6.0000000 

9.0000000 

Q18 

12 

7.9166667 

1.4433757 

4.0000000 

9.0000000 

Q20 

12 

32.8333333 

3.2983008 

28.0000000 

39.0000000 

Q22 

12 

10.8333333 

3.8336627 

7.0000000 

20.0000000 

Q23 

12 

9.4166667 

2.9682665 

6.0000000 

16.0000000 

Q24 

12 

6.5000000 

1.1677484 

4.0000000 

8.0000000 

Q25 

12 

20.6666667 

7.7146064 

15.0000000 

40.0000000 


Risk experiment: 


Comparison of performance 

' 12:21 Tuesday, July 25, 


General Linear Models Procedure 
Class Level Information 


Class 


Levels 


RISKTYPE 


Values 


C R U 


Number of observations in data set = 41 

Risk experiment: Comparison of performance 

* 12:21 Tuesday, July 25, 


General Linear Models Procedure 


Dependent Variable: FNCOST 

Source DF 

F 


Model 

0.0187 

Error 


Corrected Total 


R-Square 


Sum of 
Squares 


40 16131243.07 


Mean 

Square F Value Pr > 


3047055.74 1523527.87 4.42 


38 13084187.33 344320.72 


Root MSE 


FNCOST 


0.188892 


3004.72 


19.52887 


586.788 


Source 


DF 


Type I SS Mean Square F Value 


Pr > 




F 


RISKTYPE 

0.0187 

Source 

F 

RISKTYPE 

0.0187 


2 3047055.74 1523527.87 4.42 

DF Type III SS Mean Square F Value Pr > 

2 3047055.74 1523527.87 4.42 

Risk experiment: Comparison of performance 

* 12:21 Tuesday, July 25, 


General Linear Models Procedure 
Dependent Variable: FNSKED 


Source 

F 


Sum of 
Squares 


Mean 

Square F Value Pr > 


Model 

0.0066 

2 

27746.5886 

13873.2943 


5.75 


Error 

38 

91653.5577 

2411.9357 




Corrected Total 

40 

119400.1463 





Mean 

R-Square 

C.V. 

Root MSE 


FNSKED 

310.391 

0.232383 

15.82243 

49.1115 




Source 

F 

DF 

Type I SS 

Mean Square 

F 

Value 

Pr > 

RISKTYPE 

0.0066 

2 

27746.5886 

13873.2943 


5.75 


Source 

F 

DF 

Type III SS 

Mean Square 

F 

Value 

Pr > 

RISKTYPE 

2 

27746.5886 

13873.2943 


5.75 



0.0066 

7 

1995 


Risk experiment: Comparison of performance 

' 12:21 Tuesday, July 25, 


General Linear Models Procedure 
Dependent Variable: FNERR 


Source 

F 

Model 


Sum of 
Squares 


Mean 

Square F Value Pr > 


2 62232814.9 31116407.4 0.33 


96 




0,7182 


Error 

38 

3541740642.9 

93203701.1 




Corrected Total 

40 

3603973457.7 





Mean 

R~Square 

C.V. 

Root MSE 


FNERR 

13295.0 

0.017268 

72.61508 

9654.21 




Source 

F 

DF 

Type I SS 

Mean Square 

F 

Value 

Pr > 

RISKTYPE 

0.7182 

2 

62232814.9 

31116407.4 


0.33 


Source 

F 

DF 

Type III SS 

Mean Square 

F 

Value 

Pr > 

RISKTYPE 

2 

62232814.9 

31116407.4 


0.33 



0.7182 
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